What are you trying to optimise for? What do we gain out of having a smaller binary?

If it's specifically for prover performance: you should look at the amount of data the prover has to handle, and that's not directly related to ELF binary size: as far as I can tell, debug symbols are already ignored by the prover.

About the opt-level: you should specifically check whether going for 'z' makes your proof take longer than eg opt-level 2 or 3, if you care about that sort of thing.

@matthiasgoergens This change is simply to make the produced binary size smaller: it seems that I'll need store these binaries, and making them 2x smaller will save 2x the cost — it's that simple. Stripping them of symbols doesn't seem to hurt neither prover nor verifier while cutting unnecessary waste.

Thanks for the reply.

There are two things happening in your PR:

1. You strip the debug symbols. You are right that neither prover nor verifier care about those. It's just a bit annoying for debuggability. (We just had an occasion at my work, where having the debug symbols available proved really useful.)
2. You change the optimisation level to 'z'. That will have an impact on prover performance. It can save you a few bytes that the prover doesn't have to load, but it might cost you more VM cycles that need proving. I would suggest doing benchmarks of your individual guest programs, to determine whether that's a good trade-off.

There might be some circumstances where you want to save every last byte of the binary, even at the cost of debuggability or having extra VM CPU cycles that need proving. But my guess is that those circumstances are rare enough, that you wouldn't want to enable the flags you suggested by default for everyone under all circumstances.

However, keep in mind that I'm not associated with Succinct or SP1. So this is just my opinion, and doesn't reflect anything 'official'.

Btw, if you want to improve the default build configuration for guest programs, I would suggest enabling link time optimisation. That alone saved us 7% of cycles in our project.

Actually, there's a workaround for this, without making this change: simply add these flags to Cargo.toml of the project (workspace) building the RISC-V binary.

[profile.release]
opt-level = "z"
strip = "symbols"

So, feel free to close if this isn't adding value.

@imikushin You bring up a great point! I might be useful to stick your suggestion (together with an explanation of when one might want to do this) in a README somewhere in https://github.com/succinctlabs/sp1-project-template or as a comment inside the generated Cargo.toml in that template.

Btw, you can add lto="fat" there, too. (You should try it out for your own project, or for the examples.)

Closing in favor of succinctlabs/sp1-project-template#42